[irgen] Convert emitIRGenBuiltin to use a covered switch. #85118
Conversation
This simplifies the function and will make it easier for me to convert the function into an exhaustive switch with an NFC commit.
This should make it easier to add new builtins by "following the warnings" and prevent us from not handling a builtin in IRGen. When I did this, I discovered that if I did this naively, we would have AddressOf show up twice in the switch. This turned out to be because: 1. AddressOf is a SIL builtin that semantically is expected to only result in SIL being emitted instead of having a builtin "addressof" be emitted. 2. For what ever reason, we actually had code in IRGen to emit an AddressOf BuiltinInst if we saw it (which we never should have)... but also later code asserted that we would never see it b/c it is a "SIL only builtin". 3. When I converted the if statements to be case statements, helpfully the compiler told me I had a duplicate case. After investigation, I found the above meaning that I was able to just delete the IRGen handling. So now we properly handle AddressOf by asserting. As an additional tactic to make "SIL only builtins" even more explicit, I added code to the SIL verifier that validates we never see a builtin inst that is a "SIL only builtin" and added some comments to Builtins.def that elaborate on this.
gottesmm
requested review from
hborla,
jckarter,
rjmccall,
slavapestov and
xedin
as code owners
|
@swift-ci smoke test |
|
@swift-ci test windows platform |
1 similar comment
|
@swift-ci test windows platform |
Warning introduced by swiftlang#85118.
| case BuiltinValueKind::TypeJoinInout: | ||
| case BuiltinValueKind::TypeJoinMeta: | ||
| case BuiltinValueKind::TriggerFallbackDiagnostic: | ||
| llvm_unreachable("IRGen unimplemented for this builtin!"); |
There was a problem hiding this comment.
Is there a reasonable builtin category we could expect these to be in? I know at least some of them are lowered in SIL passes and should never make it to IRGen.
There was a problem hiding this comment.
If these are lowered in SIL passes, we could have a category of builtins that are illegal in lowered SIL (or canonical SIL if they are lowered in Raw SIL).
Really I dislike the names of our Builtin categories at this point. I think we could make them clearer (specifically, whether or not a builtin has a builtin SIL representation should be clear from the name). Another thing that might be good to cleanup is some of the polymorphic builtin stuff. I don't know if we actually use those anywhere (and if someone wants it, we can always bring it back).
Just some thoughts.
There was a problem hiding this comment.
No, I completely agree. There are several categories that I don't remember the purpose of, and there are several categories that seem very badly named.
Warning introduced by swiftlang#85118.
2 participants
This should make it easier to add new builtins by "following the warnings" and
prevent us from not handling a builtin in IRGen.
When I did this, I discovered that if I did this naively, we would have
AddressOf show up twice in the switch. This turned out to be because:
AddressOf is a SIL builtin that semantically is expected to only result in
SIL being emitted instead of having a builtin "addressof" be emitted.
For what ever reason, we actually had code in IRGen to emit an AddressOf
BuiltinInst if we saw it (which we never should have)... but also later code
asserted that we would never see it b/c it is a "SIL only builtin".
When I converted the if statements to be case statements, helpfully the
compiler told me I had a duplicate case. After investigation, I found the above
meaning that I was able to just delete the IRGen handling.
So now we properly handle AddressOf by asserting. As an additional tactic to
make "SIL only builtins" even more explicit, I added code to the SIL verifier
that validates we never see a builtin inst that is a "SIL only builtin" and
added some comments to Builtins.def that elaborate on this.